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ABSTRACT 



A method and apparatus Cor enabling any of a variety of 
devices to communicate with each other over a common or 
universal protocol. In general, a client device and a server 
device communicate with each other over a communications 
link utilizes the common protocol. Initially, once a commu- 
nications link is established, the server device identifies 
itself to the client device by sending a tag line message over 
the communications Unk. Upon receiving the tag line 
message, the client then determines that the server is capable 
of using the common protocol. The client device may then 
initiate several requests including a service request, a type 
request or a use request. If the client device initiates a service 
request, the client simple uses the common protocol to 
request the service. In response to receiving the service 
request, the server device performs the requested service and 
provides a confirmation to the client device. If the client 
device initiates a type request, the service device will 
respond by providing information regarding the services the 
server device provides and the device types supported by the 
server device. If the client device initiates a use request for 
a particular service, the server device will provide informa- 
tion to the client device that describes the necessary param- 
eters for invoking the particular service. 

22 Claims, 7 Drawing Sheets 
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UNIVERSAL PROTOCOL FOR ENABLING A 
DEVICE TO DISCOVER AND UTILIZE THE 
SERVICES OF ANOTHER DEVICE 

RELATED APPLICAnONS 

This application claims the benefit of U.S. Provisional 
Application No. 60/115,106, filed Jan. 8, 1999 and is related 
to U.S. Application Ser, No. 09/369,114, entitled "Hidden 
Agent Transport Protocol," still pending filed on Aug. 5, 
1999. 

TECHNICAL FIELD 

This invention relates to the field of data transfer proto- 
cols and, more particularly, relates to simple data transfer 
protocols capable of being used to facilitate communication 
between a wide variety of consumer devices. 

BACKGROUND 

Data transfer protocols are used to faciUtate communica- 
tion between electronic devices by providing a common set 
of rules by which data may be exchanged between one 
device and another. A universal protocol could theoretically 
allow one device to communicate with any other device, 
from simple devices like the lights in a room to complex 
devices like personal computers. However, to approach such 
an ideal, the protocol itself has to be usable with at least a 
significant proportion of the devices. Different types of 
devices have different characteristics such as microproces- 
sor abihties, firee memory, and accompanying costs. In 
addition, consumer devices are produced by a wide variety 
of manufacturers. Coordination and cooperation in interfac- 
ing a wide variety of electronic devices is very difficult. 
Thus, the need exists for a universal protocol that may be 
implemented by a large variety of device types produced by 
various manufacturers. 

Many times in the past, manufacturers have made 
attempts to allow consumer level devices to be able to 
communicate meaningful data or commands to one another. 
Many protocols define data links between standard small 
devices. However, this also meant that usually the "stan- 
dard" became only a standard for that genre of device. 
Further, while these protocols provide a data link, they do 
not provide a standard method to allow simple relevant 
information transfer between two small devices. For 
example, a typical pager cannot send control information to 
any particular cellular telephone requesting the cellular 
telephone to initiate a call to a certain number; a "caller-ID" 
box is not able to instruct a PDA to display all the contact 
information for the person who is calling; and a PDA cannot 
print or fax (without a modem or special drivers). Thus, a 
need exists for a universal protocol which can provide a 
simple data link between a wide variety of devices. 

SUMMARY 

The present invention includes a protocol and a method 
for facilitating communication between various electronic 
devices and the sharing of features, functionality and infor- 
mation between these devices. In general, the present inven- 
tion is directed towards a protocol by which one device (the 
"client device") can discover what services are offered by 
another device (the "server device"). Utilizing this protocol, 
the client device can take advantage of the services of the 
server device. Advantageously, the present invention is 
simple enough to be used by nearly any type of electronic 
device, but at the same time it is robu.st enough to allow a 
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user to author high-level applications utilizing multiple 
different services available from multiple devices without 
requiring the user to have any knowledge of any particular 
device interface or how the device works. The present 

5 invention is capable of use by a wide range of devices 
including, but not limited to, pagers, cellular telephones, 
wired telephones, caller-ID ("CID") boxes, printers, fac- 
simile machines, personal data assistant ("PDA"), personal 
computers, information sources, time pieces, stereo 
equipment, video equipment, thermostats, weather stations, 
doors, lights, and security systems. The present invention 
allows these devices to interact, by standardizing many of 
the normal tasks associated with these devices. Convergence 
Corporation, the assignee of the present invention, has 
developed a universal protocol, referred to as the Service 
Discovery Transport Protocol ("SDTP"), which embodies 
many of the aspects of this invention. Thus, embodiments of 
the present invention include a universal protocol that can be 
implement in a wide variety of device types produced by 

2^ various manufacturers. In addition, embodiments of the 
present invention provide a simple data link between these 
devices. 

The operation of a protocol implementing aspects of the 
present invention actually begins when the server device 
^5 sends a message to the client device to inform the client 
device that it ls capable of communicating using the proto- 
col. In an exemplary embodiment, this message and all 
subsequent messages may be sent using standard 8-bit 
ASCII characters. Once the client device determines that the 
server device is capable of communicating using the 
protocol, the client device may request the server device to 
identify what kinds of services the server provides. This 
request is performed by transmitting a type-command to the 
server device. 

35 Upon receiving the type-command, the server device 
responds by transmitting one or more device/service iden- 
tifiers back to the cfient device. Each device/service identi- 
fier is unique, and represents either a specific device type, 
such as a thermostat, a door, a pager, a PDA or many others, 

4Q or a specific service type, such as the ability to raise the 
temperature of the thermostat or to transmit the messages 
stored in the pager. Finally, the server device transmits a 
standard ASCII sequence to signal the last of the device/ 
service identifiers. 

45 After the server device identifies itself as being capable of 
using the protocol, the chent device may issue commands to 
the server device using the unique service identifiers just 
described. Any necessary parameters may be passed along as 
well. If everything operates correctly, the service identified 

50 by the command is then provided by the server device. 
Finally, the server device responds to each such command 
by sending a status code back to the client device. The status 
code denotes that either: (a) the requested service was 
unavailable; (b) the server device was unable to complete 

55 the operation; (c) the command contained a syntax error; or 
(d) that the operation completed successfully. 

The protocol also supports "learning" new services with 
which the client is not previously familiar. To invoke this 
capabihly, the client device transmits a use-command to the 

60 server device to identify the service that the client wishes to 
learn. Upon receiving the use -command, the server device 
transmits a service identifier corresponding to the new 
service and any available parameters. The client device may 
then invoke the service by sending the service identifier and 

65 the requisite parameters. 

Another feature of the present invention is the ability to 
drop into a different, proprietary protocol. By issuing the 
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native-command, the client device can instruct the server 
device to utilize the existing link to communicate in what- 
ever proprietary protocol is utilized for that link. 

Thus, the present invention includes at least four aspects. 
One aspect of the present invention is a protocol that allows 
a client device to request a server device to identify what 
services are provided by the server device and then allows 
the client device to request one or more of those services to 
be provided. 

Another aspect of the present invention involves the 
ability of a client device to determine whether any of a wide 
variety of server devices are capable of communicating with 
the client device using a standard protocol and then com- 
manding a particular device to carry out a particular func- 
tion. 

A third aspect of the present invention is the structure of 
the data packets that are transmitted by a server device to 
uniquely identify the device types emulated by the server 
device and the services the server device is capable of 
performing. 

A fourth aspect of the invention involves the ability of a 
client device to determine whether a particular server device 
is capable of communicating using the SDTP protocol by 
first establishing communication using any appropriate tech- 
nology and then determining if further communication is 
possible using SDTP. 

Therefore, it can be seen that these aspects of the present 
invention may be utilized within a protocol, operable within 
a variety of device types, that facilitates communication 
between the variety of device types over a simple data link. 
These and other aspects, features, and advantages of the 
present invention will be set forth in the description that 
follows and possible embodiments thereof, and by reference 
to the appended drawings and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 LS a system diagram that illustrates an exemplary 
environment suitable for implementing various embodi- 
ments of the present invention. 

FIG. 2 illustrates an exemplary environment in which the 
protocol of the present invention operates. 

FIG. 3 is an exemplary sequential diagram showing the 
basic steps of the protocol of the present invention. 

RG. 4 is an exemplary sequential diagram showing the 
basic steps of the "learning" capability of the protocol of the 
present invention. 

FIG. 5 is an exemplary sequential diagram showing how 
communication between a client device and a server device 
may be, switched from using the protocol of the present 
invention to a native, proprietary protocol. 

FIG. 6 is a state diagram illustrating the operation of the 
protocol of the present invention in a client. 

FIG. 7 is a state diagram illustrating the operation of the 
protocol of the present invention in a server. 

DETAILED DESCRIPTION 

Before describing the details of the current invention, 
some terminology used herein is described. The term "pro- 
tocol" generally refers to a set of formal rules or conventions 
describing how data is treated in an electronic system. In 
electronic communications, protocols define the electrical 
and physical standards to be observed, such as bit-ordering 
and byte-ordering and the transmission and error detection 
and correction of the bit messages, the client-server dialog, 
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character sets, and sequencing of messages, link protocols 
define the basics of how communication is established and 
maintained between two devices. Data protocols define how 
meaningful data is exchanged between the two devices using 
5 the link protocol as the underlying communication layer. 
Unless otherwise indicated, the term "protocol," as used 
below, refers to the data protocol employed by a given 
connection between two devices to communicate meaning- 
ful data, such as the discovery of information about one 
device and the issuance of commands by one device to the 
other. 

Referring now to the drawings, in which like numerals 
represent like elements throughout the several figures, 
aspects of the present invention and exemplary operating 

J 5 environments will be described. 

FIG. 1 is a system diagram that illustrates an exemplary 
environment suitable for implementing various embodi- 
ments of the present invention. FIG. 1 and the following 
discussion provide a general overview of a platform onto 

20 which the invention may be integrated or implemented. 
Although in the context of the exemplary environment the 
invention will be described as consisting of instructions 
within a software program being executed by a processing 
unit, those skilled in the art will understand that portions of 

25 the invention, or the entire invention itself, may also be 
implemented by using hardware components, state 
machines, or a combination of any of these techniques. In 
addition, a software program implementing an embodiment 
of the invention may run as a stand-alone program or as a 

30 software module, routine, or function call, operating in 
conjunction with an operating system, another program, 
system call, interrupt routine, library routine, or the like. The 
term program module will be used to refer to software 
programs, routines, functions, macros, data, data structures, 

35 or any set of machine readable instructions or object code, 
or software instructions that can be compiled into such, and 
executed by a processing unit. 

Those skilled in the art will appreciate that the system 
illustrated in FIG. 1 may take on many forms and may be 

40 directed towards performing a variety of functions. 
Examples of such forms and functions include mainframe 
computers, mini computers, servers, work stations, personal 
computers, hand-held devices such a personal data assistants 
and calculators, consumer electronics, note-book computers, 

45 lap-top computers, and a variety of other applications, each 
of which may serve as an exemplary environment for 
embodiments of the present invention. The invention may 
also be practiced in a distributed computing environment 
where tasks are performed by remote processing devices that 

50 are linked through a communications network. In a distrib- 
uted computing environment, program modules may be 
located in both local and remote memory storage devices. 

The exemplary system illustrated in FIG. 1 includes a 
computing device 10 that is made up of various components 

55 including, but not limited to, a processing unit 12, non- 
volatile memory 14, volatile memory 16, and a system bus 
18 that couples the non-volatile memory 14 and volatile 
memory 16 to the processing unit 12. The non- volatile 
memory 14 may include a variety of memory types 

60 including, but not limited to, read only memory (ROM), 
electronically erasable read only memory (EEROM), elec- 
tronically erasable and programmable read only memory 
(EEPROM), electronically programmable read only 
memory (EPROM), electronically alterable read only 

65 memory (EAROM), and battery backed random access 
memory (RAM). The non -volatile memory 14 provides 
storage for power on and reset routines (bootstrap routines) 
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that are invoked upon applying power or resetting the remote systems, such as a remote computer 38. The remote 

computing device 10. In some configurations the non- computer 38 may be a server, a router, a peer device or other 

volatile memory 14 provides the basic input/output system common network node, and typically includes many or all of 

(BIOS) routines that are utilized to perform the transfer of the components described relative to the computing device 

information between the various components of the com- 5 10. When used in a networking environment, the computing 

puting device 10. device 10 is connected to the remote system 38 over a 

The volatile memory 16 may include a variety of memory network interface 28. The connection between the remote 

types and devices including, but not limited to, random computer 38 and the network interface 28 depicted in FIG. 

access memory (RAM), dynamic random access memory 1 may include a local area network (LAN), a wide area 

(DRAM), FLASH memory, EEROM, bubble memory, network (WAN), a telephone connection, or the like. These 

registers, or the like. The volatile memory 16 provides types of networking environments are commonplace in 

temporary storage for program modules or data that are offices, enterprise -wide computer networks, intranets and 

being or may be executed by, or are being accessed or the Internet. 

modified by the processing unit 12. In general, the distinc- u wUl be appreciated that program modules implementing 

tion between non-volatile memory 14 and volatile memory various embodiments of the present invention may be stored 

16 is that when power is removed from the computing in the storage device 32, the non-volatile memory 14, the 

device 10 and then reapphed, the contents of the non-volatile volatile memory 16, or in a networked environment, in a 

memory 14 is not lost, whereas the contents of the volatile remote memory storage device of the remote system 38. The 

memory 16 is lost, corrupted, or erased. program modules may include an operating system, appli- 

The computing device 10 may access one or more exter- cation programs, other program modules, and program data, 

nal display devices 30 such as a CRT monitor, LCD panel, The processing unit 12 may access various portions of the 

LED panel, electro-luminescent panel, or other display program modules in response to the various instructions 

device, for the purpose of providing information or com- contained therein, as well as under the direction of events 

puting results to a user. The processing unit 12 interfaces to occurring or being received over the input interface 24 and 

each display device 30 through a video interface 20 coupled ^5 the network interface 28. 

to the processing unit over system bus 18. piG. 2 iUustrates an exemplary environment in which the 

The computing device 10 may have access to one or more protocol of the present invention operates. As shown, the 

external storage devices 32 such as a hard disk drive, a environment comprises a plurality of devices 200-205, 

magnetic disk drive for the purpose of reading from or represented by circles. As used herein, "devices" include 

writing to a removable disk, and an optical disk drive for the 3Q server devices 200-202, client devices 203, and client/server 

purpose of reading a CD-ROM disk or to read from or write devices 204-205. The server devices 200-202 are capable of 

to other optical media, as well as devices for reading from providing one or more services or carrying out one or more 

and or writing to other media types including but not limited functions. The client devices 203 are capable of instructing 

to, FLASH memory cards, Bernoulli drives, magnetic the server devices 202 to carry out a designated function or 

cassettes, magnetic tapes, or the like. The processing unit 12 35 service via a communications link represented by a broken 

interfaces to each storage device 32 through a storage line in FIG. 2. A service could be an external operation, such 

interface 22 coupled to the processing unit 12 over system as adjusting the temperature of a thermostat or switching the 

bus 18. The storage devices 32 provide non- volatile storage lights in a room on or off, or it might involve additional 

for the computing device 10. communication between the server device and the client 

llie computing device 10 may receive input or commands 40 device, such as sending a telephone number from a PDA to 

from one or more input devices 34 such as a keyboard, a laptop computer. However, a client device is only capable 

pointing device, mouse, modem, RF or infrared receiver, of communicating a service request to a server device if the 

microphone, joystick, track ball, light pen, game pad, client device and the server device are capable of commu- 

scanner, camera, or the like. The processing unit 12 inter- nicating using a common protocol. Unfortunately, in today's 

faces to each input device 34 through an input interface 24 45 environment, common protocols are usually shared only by 

coupled to the processing unit 12 over system bus 18. The devices produced by the same manufacturer, or by using 

input interface may include one or more of a variety of such devices as modems or special drivers, 

interfaces, including but not limited to, an RS-232 serial port As illustrated in FIG. 2, a particular device 200-205 may 

interface or other serial port interface, a parallel port be both a server device and a client device such as client/ 

interface, a universal serial bus (USB), an optical interface 50 server devices 204-205. The client/server devices 204-205 

such as infrared or IRDA, an RF or wireless interface such may be capable of instructing other server devices to carry 

as Bluetooth, or other interface. out a designated function while, at the same time, may carry 

The computing device 10 may send output information, in out a function itself. For example, in its client role, a laptop 

addition to the display 30, to one or more output devices 36 computer might need to retrieve data from a PDA carried by 

such as a speaker, modem, printer, plotter, facsimile 55 a user, and then in its server role, the laptop might be called 

machine, RF or infrared transmitter, or any other of a variety on by the user to provide a telephone number directly to a 

of devices that can be controlled by the computing device cellular telephone. Thus, the laptop functions as both a client 

10, The processing unit 12 interfaces to each output device device and a server device. However, in the following 

36 through an output interface 26 coupled to the processing description, each device will be discussed only in its role as 

unit 12 over system bus 18. The output interface may include 60 either a client device or a server device, 

one or more of a variety of interfaces, including but not FIG. 3 is an exemplary sequential diagram showing the 

limited to, an RS-232 serial port interface or other serial port basic steps of the protocol of the present invention. It is 

interface, a parallel port interface, a universal serial bus important to note that this diagram is meant to depict only 

(USB), an optical interface such as infrared or IRDA, an RF the basic functionality of the protocol, and that actual use of 

or wireless interface such as Bluetooth, or other interface. 65 the protocol will commonly involve a greater or lesser 

llie computing device 10 may operate in a networked number of steps. Further, it is important to note that the steps 

environment using logical connections to one or more shown and described do not all have to take place in the 
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sequence shown. The sequence represents only a typical use 
of the available protocol functions which may or may not be 
followed in actual use. 

As shown in FIG. 3, use of the protocol of the present 
invention does not begin until communication between a 5 
client device and a server device is already established at 
Step 300 using a link protocol, also referred to as a link layer. 
The protocol of the present invention does not require the 
use of a specific link layer, but in an exemplary embodiment, 
the protocol may impose certain requirements such as: 1) jq 
allowing for serial ASCII data transfer; and 2) if binary data 
is to be sent, using standard UUEncode/UUDecodc routines 
to provide the proper conversions to and from ASCII data. 
Existing link layers which meet these requirements include, 
but are not limited to, serial cable, IrDA, Bluetooth and 
TCP/IP sockets. 

If a device provides a service, it must be running a 
protocol server Once a connection 300 using the link layer 
is complete, the server will identify itself as being capable 
of communicating using the protocol of the present inven- 20 
tion by issuing a tag Une message 301. The issuance of the 
tag line message 301 signals the actual start of the operation 
of the protocol of the present invention. In an exemplary 
embodiment, the tag line message 301 and all subsequent 
messages are sent using standard 8 -bit ASCII characters. In 25 
the illustrated embodiment, the tag line message 301 is in the 
following format: 

PROTOCOLNAME VER:N.N [COMMENTS], 
where PROTOCOLNAME is the name of the protocol, N.N 
is the current version of that protocol, and COMMENTS is 30 
an optional field which can be used to describe the 
manufacturer, the date of manufacture, or the like. As 
previously mentioned, Convergence Corporation has devel- 
oped a universal protocol, called Service Discovery Trans- 
port Protocol ("SDTP") which embodies many of the 35 
aspects of this invention. Thus, in the example shown in 
FIG. 3, the SDTP-enabled server transmits the following tag 
line message: 

SDTP VER:1.0 Convergence Corporation 1998. 
Further description of the protocol of the present invention 40 
will focus on this specific, exemplary embodiment, but it 
should be understood that the present invention is not 
limited to the specifics of the SDTP protocol. 

Once the server device issues the tag line message 301, 
the client device may request the server device to identify 45 
the device types it supports and the services the server 
device provides. This request is performed by transmitting a 
type -command 302 to the server device. The type-command 
could be implemented in a variety of forms, but in the 
illustrated embodiment, the type-command 302 comprises 50 
the word "TYPE." Although it is common for the client 
device to send the type-command 302, it should be under- 
stood that sending the type-command is not a required step. 
For example, a client device may already be aware that a 
particular service is available from the server device. 55 
Advantageously, this may save time in the communication 
process. 

If the server device receives the type-command 302, the 
server device transmits to the client device a data packet 
303-306 describing the devices and services provided by the 60 
server device. The data packet 303-306 contains several 
data fields. Among the data fields are one or more device/ 
service identifiers 303-305, each of which represents either 
a specific device type or a specific service type. For example 
a device type may include a thermostat, a door, a pager, a 65 
PDA or the like. A service type may include the ability to 
raise the temperature of a thermostat or to transmit the 



messages stored in a pager. Although the device/service 
identifier may be implemented in a variety of forms, in the 
illustrated embodiment, the device/service identifier subsists 
in the following form: 
XjXjXj-NAME 

where NAME is a short (7 characters or less) description of 
the device or the service, and x^x^Xj is a unique three 
character "identifier." Each of the three characters of the 
three character identifier is chosen from an alphabet con- 
sisting of the characters: 

[0...9], [a...z], and [A . . . Z], 
In addition, the x^, x^ and X3 characters are chosen such that 

forms a unique value. This technique allows for 12161 
unique device/services to be used under SDTP while at the 
same time only requiring 16-bit math to be used when 
describing a device or a service. 

A SDTP server must be able to provide the functionality 
of at least one device to be classified as a SDTP server. Thus, 
the data packet 303-306 sent by the server device must 
include at least one device identifier 303. In the example 
shown in FIG. 3, the device identifier is Xi^X2aX3^- 
THRMST. In addition, because most server devices support 
a variety of services, the device identifier 303 is usually 
followed by multiple service identifiers 304-305, In the 
example shown in FIG, 3, the service identifiers are 
Xi^X^sXa^-TMPHIGH 304 and X^c^^c^^'^^^OW 
305. In addition, multiple device identifiers (not shown) may 
be sent if the server supports multiple device types. For 
example, a cellular telephone that may also function as a 
pager would send a device identifier for both the cellular 
telephone and the pager. 

In an exemplary embodiment, each individual device/ 
service identifier 303-305 is sent as a single line of data and 
is limited to a maximum of 64 characters in length. 
Advantageously, this technique allows devices having a 
hmited amount of RAM to receive and process a full line of 
data without facing an overflow condition. The end of a line 
of data is signaled by transmitting the ASCII <newline> 
character. Upon transmission of the final data packet 
303-306 by the server device, the end of the response is 
signaled by transmitting an end of response message 306. In 
an exemplary embodiment, an end of response message 306 
includes the ASCII characters "," and "<newline>". Thus, 
the basic structure of a server device data packet sent in 
response to a type-command would be as follows: 



ID:DEVICEID[CX>MMON NAMElCXDMMENTS]<ncwliac> 

SD:[SERVICEIDl][SD_COMMENTSl]<ncwline> 

SD:[SERVICEID2]ISD_COMMENTS2]<ncwlinc> 

I 

I 

I 

.<ncwlinc> 



where: 

DEVICEID uniquely identifies a particular type of device, 

COMMON NAME uniquely identifies a particular device 
of the type DEVICEID. 

COMMENTS contains additional meaningful informa- 
tion about the device, 

SERVICEIDl and SERVICEID2 uniquely identify par- 
ticular services, and 

SD.COMMEN'l-Sl and SD_C0MMENTS2 contain 
meaningful information about the services SERVI- 
CEIDl and SERVICEID2, respectively. 
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SD:X^X6j3X6c-TIME<newIine> 



.<newline> 
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In an exemplary embodiment, the COMMON NAME 
field is no more than 16 characters in length to minimize 
device memory requirements. Additionally, in an exemplary 
embodiment the COMMON NAME field is user customiz- 
able at the SDTP server level. This field is utilized by the 
user of a client device to recognize which particular device 
of the type "DEVICEID" is involved. Examples of suitable 
names of devices include "BobsPager," "JefifePDA," and 
"CommonPrinter." 

The contents and the use of the various comments fields 
are completely optional. For example, COMMENTS may lo 
include information such as "Laser printer on 4th floor." 
Similarly, if the server device is a pager and the first service 
provided is the transmission to the client device of page 
information which has been stored in the pager, 
SD_C0MMENTS1 might be "Page Information." 

To illustrate the use and meaning of the DEVICEID and 
SERVICEID data fields and their relationship with the 
operation of the protocol of the present invention, an exem- 
plary server device will next be discussed. Referring again 
to FIG. 1, one device operable in accordance with the 
protocol of the present invention is a pager unit. The pager 20 
includes a processing unit, a memory, and a bus that couples 
the memory to the processing unit. The pager is capable of 
receiving pages via wireless signal transmission and storing 
page information in the memory. A user may enter com- 
mands and information into the pager through the use of a 
keypad. A LED or LCD display may be used to display page 
information when received or when retrieved from memory. 
A speaker is provided to indicate the reception of a page. In 
addition to being able to receive pages via traditional 
wireless signal transmission, a pager that includes an 
embodiment of the present invention is also able to com- 
municate directly with other devices. The pager carries out 
this communication using one or more communications 
means selected from a wide variety of communications 
technologies. The communication means may be utilized by 
the pager to transmit to another device and to receive 35 
information from another device. Although current pagers 
may or may not be equipped with the appropriate commu- 
nications means necessary for complete implementation of 
the protocol of the present invention, it should be understood 
that suitable communications technologies currently exist 
and that the selection and implementation of one or more of 
these technologies would be obvious to one of ordinary skill 
in the art. 

According to an exemplary method of operation of the 
protocol of the present invention, the pager carries a unique 
device identifier (DEVICEID) such as XjXsXg-lWAYPGR, 
where XjXjXg is selected according to the previously- 
described criteria for uniqueness. Services provided by the 
pager may include a status check, a transmission of the last 
page received by the pager, a transmission of a specified 
page previously received by the pager, a transmission of a 
list of identifiers for pages currently stored in the pager's 
storage means, a transmission of a current clock reading 
and/or an update of the clock. Each service carries a unique 
service identifier in the form XJX2X3-NAME, as previously 
described. Thus, the pager may carry the services with 
service identifiers (SERVICEID*s) x^x^Xg-STAT, x^x^Xg- 
PAGERX, XjX^Xs-PAGE, x^x^Xs-LIST, x-,X2X3-TIME and/ 
or XjX^Xg-TIMESET, corresponding respectively with the 
above-identified services. 

A common one-way pager that supports page reception, 
time reporting, and time setting, might respond to a type- 
command with the following data packet: 

ID:X4^X4^X4e-l WAYPGR<newline> 



10 



where ''X^X^gX^c" "^sa^sb^sc" "^M^eB^ec" 



and 



"X7^X7^X7c" are examples of possible unique device and 
server identifiers (DEVICEID and SERVICEID's, 
respectively). 

As mentioned previously, other exemplary embodiments 
of server devices capable of using the protocol of the present 
invention include, without limitation, a two-way pager, a 
voice pager, a cellular telephone, a PDA, a personal 
computer, a wired telephone, a CID box, a printer, a fax 
machine, a clock, audio equipment, video equipment, a 
thermostat, an email device, a security system, and a generic 
information device. These devices and a non-exclusive list 
of services that might be offered by these devices are listed 
in Table 1, along with exemplary unique ids for the devices 
or services. 

TABLE 1 



Device 



Device ID 



Service 



Service [D 



One-way 
pager 



X 1X2X3- 

1 WAYPGR 



1^0- way 
pager 



2WAYPGR 



Voice pager 



X1X2X3- 
VOCPGER 



45 



Cellular 
phone 



X1X2X3- 
CELLULR 



50 



55 



Personal 
Data 

Assistant 



XJX2X3-PDA 



65 



Status of the pager x 1X2X3- STAT 



Last page received 
Displays a page from t 
LIST command 
Register 
List pages 
Return the current 
time/date 
Set the time 
Status of the pager 

Last page received 
Displays a page from a 
LIST command 
Transmits a page 
Register 
List pages 
Return the current 
time/date 
Set the time 
Status of the pager 

Last page received is 
played 

Play a page from a 
LIST command 
Register 
List pages 
Return the current 
time/date 
Set the time 
Status of the phone 

Dials a phone number 
(or instructs to dial) 
Register 

List numbers in the 
phone's number list 
Add a phone number 
to the list 
Clears a list entry 
Return the current 
time/date 
Set the time 
PDA status 

Specifics a new 
calendar event 
Lists upcoming 
calendar events 
Lists contacts 
Adds a new contact 
Search for a contact 
Return the current 
time/date 
Set the time 



X1X2X3-PAGERX 
X 1X2X3- PAGE 

X 1X2X3- REGSTR 
X 1X2X3- LIST 
XiXjXj-TIME 

X1X2X3-TIMESET 
X 1X2X3- STAT 

X1X2X3-PAGERX 
X1X2X3-PAGE 

XiXjXj-PAGETX 
X1X2X3-REGSTR 
X1X2X3-LIST 
X1X2X3-TIME 

X1X2X3-TIMESET 
XiXjXj-STAT 

X1X2X3-PAGERX 

X 1X2X3- 

PLYPAGE 
X1X2X3-REGSTR 
X 1X2X3- LIST 

XiX2X3-'I'tME 

XiXaXj-TIMESET 
XiXaXj-STAT 

X 1X2X3- DIAL 

X1X2X3-REGSTR 
X1X2X3- 
LISTNUM 
X1X2X3-ADDLIST 

X1X2X3-CLRLIST 
XtXjXjTIME 

X1X2X3-TIMESET 
XiX2X3-STAr 

XiXjXj-CALEVT 

X 1X3X3- LISTCAL 

X 1X2X3- LISTCON 
X1X2X3-NEWCON 
X1X2X3-SEARCH 
X1X2X3-TIME 

X1X2X3-TIMESET 
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TABLE 1 -continued 



TABLE 1 -continued 



Device 



Device ID 



Service 



Service ID 



Device 



Etevice ID 



Service 



Service ID 



Personal 
Computer 



X,X2X3-PC 



Wired 
Telephone 



TELEPH 



CID box X1X2X3-CID 



PC status 

Specifies a new 
calendar event 
Lists upcoming 
calendar events 
Lists contacts 
Adds a new contact 
Search for a contact 
Transmits a file 
Receives a file 
Return the current 
time/date 
Set the time 
Phone status 

Dials a phone number 

Register 

Lists the phones 

number list 

Adds to the phones 

number list 

Clears an entry in the 

phones list 

Return the current 

time/date 

Set the time 

Caller ID status 

Register 

List alt caller ID's 



Last call received 
Attempt to identify a 
phone number 
Return the current 
time/date 
Set the time 

Printer XiX:;X3- PRINT Printer status 

Print a 51e 
Return the current 
time/date 
Set the time 

Fax machine XiXjXj-FAX Fax status 

Dials a phone number 
Send a fax 
Register 

List fax numbers 

Add to the fax 
numbers list 
Clear an entry to the 
list 

Return the current 

time/date 

Set the time 

Clock X1X2X3-CLOCK Clock status 

Return the current 
time/date 
Set the time 
Last alarm 
Set an alarm 

Clear an alarm 

Lists alarm 



XjXjXj-DIAL 
XjXjXj-REGSTR 

XjXjXj- 

LISTNUM 
XjXjXj-ADDLIST 

XjXjXj-CLRIJST 

XiXjXj-TIME 

X1X2X3-TIMESET 

XiXjXj-STAT 

x^XjXa-REG^rR 

XiXjXj- 

LISTNUM 

X1X2X3-LATEST 

X1X2X3-CALLID 

X1X2X3-TIME 

XiXjXa-TIMESET 
XjX^Xa-STAT 
X1X2X3-PRINT 
XjXjXj-TIME 

X1X2X3-TIMESET 

XjXzXj-STAT 

XiX^Xj-DIAL 

X1X2X3-FAX 

XiX2X3-REGSTR 

XjXjXj- 

LISTNUM 
X1X2X3-ADDLIST 

x,X2X3-CLRUST 

X1X2X3-TIME 

X1X2X3-TIMESET 

XiX2X3-STAr 

x,X2X3-TIME 

x,X2X3-TIMESET 
X1X2X3-ALARM 

X 1X2X3- 

ALARMSET 

X1X2X3- 

AIJVRMDEL 

X,X2X3-LIST 



X 1X2X3- STAT 

X1X2X3-CALEVT 

x,X2X3-LISTCAL 

X1X2X3-LISTCON 

X1X2X3-NEWCON 

X1X2X3-SEARCH 

X1X2X3-FILETX 

XiX2X3-RLERX 

x,X2X3-TIME 

XjXjXj-TIMESET 
X1X2X3-STAT 



^ Stereo 
Equipment 



10 



X 1X2 X3- 

STEREO 



15 



20 



25 



Video 
Equipment 



X1X2X3-VIDEO 



30 



35 



Video 

Equipment 

(coat.) 



50 Thermostat/ 
Thermo- 
meter 



55 



X1X2X3- 
THERMO 



60 



Stereo status 

Current tuned 
frequency 
Set the frequency 
T\ine up 
TUne down 

Volume up 
Volume down 
Volume set 
On 
Off 

Play media 

Change track up 

Change track down 

Set the track 

Fast forward 

Rewind 

Mute 

Stop 

Pause 

Record 

Lists media 

Return the current 

time/date 

Set the time 

Status 

Channel up 
Channel down 
Current channel 
Set chaiuel 

Volume up 
Volume down 
Set volume 
On 
Off 

Switch video media 
Play media 
Track up 
Track down 



XjXjXj-STAr 

X1X2X3-FREQ 

XiXaXg-FREQSEr 
X 1X3X3- FREOUP 

X 1X2X3. 

FREODWN 

X,X2X3-VOLUP 

X 1X2X3- VOLDN 

X 1X2X3- VOLS ET 

X1X2X3-ON 

X1X2X3-OFF 

X1X2X3-PLAY 

X1X2X3-TRKUP 

x,X2X3-TRKDWN 

x,X2X3-TRKSET 

X,X2X3-FF 

XjXjXj-REW 

XiX2X3-MUTE 

X1X2X3-STOP 

X1X2X3-PAUSE 

X1X2X3-RECORD 

X1X2X3-LIST 

X1X2X3-TIME 

X1X2X3-TIMESET 
XiX2X3-STAr 

X1X2X3-CHUP 
X1X2X3-CHDWN 

XiX2X3-CIINL 

X1X2X3- 

CHNLSET 
X1X2X3-VOLUP 
X 1X3X3- VOLDN 
X 1X3X3- VOLSET 
X1X2X3-ON 
X1X2X3-OFF 

xiX2X3-swrrcH 
X1X2X3-PLAY 
X1X2X3-TRKUP 
X1X2X3-TRKDWN 



Set track 
Fast forward 
Rewind 
Mute 
Stop 
Pause 
Record 
Lists media 
Return the current 
time/date 
Set the time 
Thermostat status 

Set the high 
temperature 
Set the low 
temperature 
Force AC to be 
turned on 
Force heat to be 
turned on 

Force AC to be turned 
off 

Force heat to be turned 
off 

Force fan to be turned 
on 

Force fan to be turned 
off 

Return the current 
time/date 
Set the time 



X1X2X3-TRKSET 
X1X2X3-FF 

XtX2X3-REW 

X1X2X3-MUTE 

XiX2X3-SriDP 

XjXjXj-PAUSE 

X 1X2X3- RECORD 

XiXjXa-LIST 

X1X2X3-TIME 

X1X2X3-TIMESET 
X 1X2X3- STAT 

X1X2X3- 

TMPHIGH 

X1X2X3-TMPLOW 

X1X2X3-ONAC 

X1X2X3-ONHEAT 

X1X2X3-OFFAC 

X 1X2X3- 

OFFHEAT 
X1X2X3-ONFAN 

X1X2X3-OFFFAX 

X1X2X3-TIME 

X1X2X3-TIMESET 
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TABLE 1-continued 



Device 



Device ID 



Service 



Service ID 



Generic 

Information 

Device 



GENERIC 



Status of the 
information device 



XiXjXj-STyVr 



List information 
identifiers 

Display info from id 
List sub- information 
List possible query 
Make query 
Return the current 
time/date 
Set the time 
Email device XjXzXj-EMAIL Status of email 
device 
Send email 
List emails 
Display emails 
Return the current 
time/date 
Set the time 
Security system status 



10 



Security 
System 



X1X2X3- 
SECURTY 



IXira security system 
on 

TXim security system 
off 

Register 

Return the current 

time/date 

Set the time 



X1X2X3-LIST 

XiXjXj-DISPL 

XiX2X3-LISnD 

X1X2X3-LISTO 

X1X2X3-OUERY 

X1X2XJ-TIME 



XiXzXj-TIMESET 
X1X2X3-STAT 15 

X1X2X3-SEND 

X,X2X3-LIST 

X1X2X3-EMAIL 
x,X2X3-TIME 

X1X2X3-TIMESET 
X1X2X3-STAT 

XjXaXj-ON 

X1X2X3-OFF 



25 



X1X2X3-REFSTR 
X1X2X3-TIME 

XiX2X3-TIMESET 



35 



Referring again to FIG. 3, at any time after the server 
device issues the protocol tag line message 301, the client 
device may command the server device to carry out specific 
services using the unique service identifiers just described. 
For example, the cUent device may issue a service-command 
307 XicX2<-X3c-TMPL0W 65. However, as shown in FIG. 
3, service -commands are typically issued after the client 
device first determines what services are available by issuing 
the type-command 302. A service -command 307 may be 
issued by transmitting either the full device identifier 
(X1X2X3-NAME) or just the unique three letter prefix 

1^2x3)- necessary parameters may be passed along as 
well. For example, the following command might be used to 
set a threshold temperature of 65 degrees Fahrenheit at 
which the thermostat turns on the heat: 

X1CX2CX3C-TMPLOW 65. 

Alternatively, the following simplified command might be 
used to accomplish the same task: 

Unless the communication between the client device and 
the server device using the protocol fails, the server device 
will provide some sort of status- response to a service- 
command 307 issued by the client device. As shown in FTG. 
3, a successful-completion response 308 is sent to the server 
device to confirm the completion of the requested task. An 
exemplary successful -completion response 308 could be 55 
formatted as follows: 

XjX2X3-0IC 

where x 1X3X3 is the identifier of the requested service. 
Alternatively, a server device might return other data in 
addition to or in lieu of the usual successful-completion 60 
response 308 described above. For example, upon success- 
fully setting the clock of a server device to a specified time, 
the device might send a response echoing the time which 
was set. 

Other status responses are sent by the server device to 
indicate other conditions. For example in an exemplary 
embodiment, XjXjXg-NOSERV could be sent when a 
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requested service is unavailable. As another example, 
X1X2X3-NOTDONE could be sent when a requested service 
is available, but the server device is unable to successfully 
complete the requested service. Likewise, X1X2X3-SYNTAX 
could be sent when a service-command contains a syntax 
error. It should be obvious to one of ordinary skill in the art 
that other status-responses, in addition to, or in lieu of, the 
above-described ones, may be tised as well and the present 
invention is not limited to any particular set. 

In an exemplary embodiment, the server device signals 
the end of its status-response by sending the and "<new- 
linc>" character. The cUcnt device ends further chent-servcr 
communication by transmitting a quit-command 310 to the 
server device. In an exemplary embodiment, the quit- 
command may comprise the word "QUIT" or a similar 
indicator. In response to receiving a quit-command, the 
server closes the protocol connection using whatever 
method the server needs to disconnect the client, and the 
operation of the protocol is complete. 

FIG. 4 is an exemplary sequential diagram showing the 
operation of the "learning" capability of the protocol of the 
present invention. As with FIG, 3, it is important to note that 
the steps shown and described do not all have to take place 
in the sequence shown, and that the sequence represents only 
a typical use of the available protocol functions which may 
or may not be followed in actual use. 

The learning capability is invoked by a client device 
which wishes to know how to use a particular service. In an 
exemplary embodiment, a client device invokes this process 
by issuing a use-command. An exemplary format for a 
use-command is as follows: 

USE X1X2X3-NAME. 
where XiX2X3-NAME is the service identifier of a service the 
client device wishes to learn how to use. As shown in FIG. 
4, the use-command 400 may be issued by the client device 
after it receives a response to a type-command 302; 
however, the use -command 400 may also be issued without 
first issuing and receiving a response to a type-command. 

In response to receiving a use-command 400, the server 
transmits a use -response 401 to the client device explaining 
how the identified service is used. In an exemplary 
embodiment, the server device's use-response 401 to the 
use -command 400 is in the following format: 

x,X2X3-NAME P[PARAMTYPE] P[PARAMTYPE] . . . 
DpESCRIPnON] 
where PARAMTYPE is the type of the parameters the 
service command requires. The description is a short 
description of the parameters. The parameters may include, 
but are not limited to, a generic string of characters, a set of 
pre-defined options ("choices") from which the client device 
may choose when invoking the service such as a time, a 
boolean "yes or no" option, an ID, or the like. 1able 2 is a 
non-exhaustive list of parameters and their descriptions that 
might be included in the server device's use-response. 

TABLE 2 



PARAMTYPE 



DESCRIPTION 



S String generic string input 

C<CH0ICE1| Choice - Where the client selects from a set of 

CH0ICE2|. . .> Choices described by <CHOICEl|CHOICE2|etc> 
T rune 

B<FLAG]|FLAG2> Boolean - Client can select from either FLAGl or 
FLAG2 

I ID - Used in SDTTP list ID's when a service lists 

ID'S that are unique for this session only to 
identify an ttem from a UST. 



65 



FIG. 5 is an exemplary sequential diagram showing how 
communication between a client device and a server device 
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may be switched from using the protocol of the present 
invention to a native, proprietary protocol. As with FIG. 3, 
it is important to note that the steps shown represent only a 
typical use of the available protocol functions which may or 
may not be followed in actual use. ^ 

The "native" capability is geoeraUy controlled by the 
client device. When the client device using the SDTP 
protocol wishes to use the underlying communications link 
for another data protocol instead, the client device may send 
the native -command 500 to the server device. In an exem- 
plary embodiment, the native-command comprises the word 
"NATIVE." As shown in FIG. 5, the native-command may 
be issued at any time after the server device issues the tag 
line message 301. Upon receiving the native-command, the 
server may respond by sending a native-response 501. In an 
exemplary embodiment, the native-response corresponding is 
to the native-command 500 may be formatted as follows: 

NATIVE OK<newline>. 
In addition, the server will switch control over to the native 
protocol used for this link. Alternatively, the server may 
respond to the native-command by sending an error code 20 
response. In this case, further communication between the 
client and server continues to utilize the SDTP protocol 
rather than switching to the native protocol. 

Once communication switches to the native protocol, 
further SDTP communications are dependent on the native 25 
protocol reinstalling the SDTP server on the link after the 
transfer is completed. However, the SDTP client is discon- 
nected and will have to reestablish an SDTP connection to 
use SDTP services. Typically this is done by disconnecting 
the link altogether and then reconnecting. If the devices are 30 
permanently connected, however, then an application-level 
"reset" could be executed to force the SDTP server to 
reinitialize and send the SDTP tag line message 301 once 
again. 

FIGS. 6-7 are state diagrams illustrating the operation of 35 
the client device and the server device, respectively, using an 
exemplary embodiment of the protocol of the present inven- 
tion. Operation of the protocol in both the client device and 
the server device includes multiple static states and multiple 
transitional states. 'The static states are shown as solid circles 40 
and represent the status of a device at a given time. 

Transitions from one static state to the next occur in 
response to specific events. The events triggering such a 
transition vary from static state to static state, so an event 
triggering a transition when a device is in one state does not 45 
necessarily effect such a transition when the device is in 
another state. Once a device enters a particular static state, 
the device remains in that state until one of the triggering 
events associated with that state occur. 

The events which trigger a transition are outside the 50 
control of the protocol. In a preferred embodiment, opera- 
tion of the protocol is controlled by a higher-level applica- 
tion. Thus, the application controls when a particular trig- 
gering event occurs. 

A transition between static states may result in passing 55 
through one or more transitional states. In a transitional 
state, a specific action is performed and the transitional state 
is automatically exited upon completing the action. The 
automatic transition from a transitional state is illustrated by 
a broken line. Thus, each event results in a transition from 60 
one static state to another static state with the possibility of 
passing through a transitional state. 

As shown in FIG. 6, the operation of a client device using 
the protocol of the present invention includes seven static 
states (IDLE 600, UNKING 602, READY 603, WAIT/ 65 
ITPE 606, WAIT/USE 609, WAIT/SERVICE 612 and 
NATIVE 615) and eight transitional states (TRY HOOKUP 



601, TYPE 605, USE 608, SERVICE 611, NATIVE 614, 
QUIT 617, EXIT 618 and RESTART 619). The static states 
are defined as follows: 

IDLE the client device is not currently in communication 

with the server device; 
LINKING the client device has attempted to initialize 
communication with the server device but has not yet 
received a SDTP tag line message from the server 
device; 

READY the client device has established communication 
with the server device and is ready to send a command 
to the server device; 

WAIT/TYPE the client device is waiting on a response to 
the type-command; 

WAITAJSE the client device is waiting on a response to 
the use -command; 

WAIT/SERVICE the client device is waiting on a 
response to a request for a particular service; and 

NATIVE communication with the server device using the 
SDTP protocol has been discontinued, but the under- 
lying link is still in existence. 

The transitional states are shown as diamond boxes and 
represent a particular action taken by the client. The actions 
taken are defined as follows: 

TRY HOOKUP the client device sends a link request to 
the server device; 

TYPE the client device sends a type-command to the 
server device; 

USE the client device sends a use-command to the server 
device; 

SERVICE the client device sends a service-command to 

the server device; 
NATIVE the client device sends a native -command to the 

server device requesting that the server device switch 

communications to native; 
QUIT the client device sends a quit-command to the 

server device; 

EXIT the client device ends all communications with the 
server device; and 

RESTART in some circumstances, the client device 
requests SDTP to be reestablished directly. 

Initially, the IDLE state 600 is active. If communication 
with a target server device is desired, the IDLE state 600 is 
exited and at 601 the client transmits the appropriate signal 
or signals to the target server device before entering the 
LINKING state 602. Any communications between the 
client device and the target server device are being carried 
out using an underlying link protocol as described previ- 
ously. While in the LINKING state 602, the client device 
may receive a tag line message 301 from the target server 
device indicating that the device is SDTP-enabled. When the 
tag line message is received 620, the READY state 603 is 
entered. 

The READY state 603 is the basic operational state of the 
SDTP protocol on a client device, A transition out of the 
READY state 603 occurs in response to one of several 
events. In response to a type-request event 604, a type- 
command 605 is sent to discover the type and services of the 
target server device, now referred to as the server device. 
After sending the type-command 605 the WAIT/TYPE state 
606 is entered. If the client device receives a response to the 
type-command, the READY state 603 is re-entered. Another 
event that may occur in the READY state 603 is the 
occurrence of a use -request event 607. In response to a 
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use -request event 607, a use-command 608 is sent to dis- 
cover how to use a particular service. After sending a 
use-command 608 the WATTAJSE state 609 is entered. If the 
client device receives a response to the use-command, the 
READY state 603 is re-entered. Another event that may 5 
occur is the occurrence of a service-request event 610. In 
response to a service -request event 610, a service-command 
611 is sent to request that a particular service be performed 
by the server device. After sending a service-command 611 
the WAIT/SERVICE state 612 is entered. If the client device lO 
receives a response to the service-command, the READY 
state 603 is re-entered. Another event that may occur is the 
occurrence of a native-request event 613. In response to a 
native-REQUEST EVENT 613, a native -command is sent to 
halt communications using the SDTP protocol and initiate is 
communications between the two devices using a native 
protocol. After sending the native-command 614 the 
NATIVE state 615 is entered. Another event that may occur 
is the occurrence of a quit-request event 616. In response to 
a quit-request event 616, a quit-command 617 is sent to halt 20 
communications between the two devices. After sending the 
quit-command 617 to the server device the IDLE state 600 
is re-entered. 

In the NATIVE state 615, the client device may continue 
communicating with the server device using some other data 25 
protocol, such as Simple Mail Transfer Protocol ("SM'IT") 
or HyperText Transfer Protocol ("HTTP"). Generally, when 
no further communication between the client device and the 
server device is desired, an exit procedure 618 is performed 
and the IDLE state 600 is re-entered. Communications using 30 
the SDTP protocol may then be reinitialized as described 
previously. As previously described, however, there are 
some cases in which a client device in the NATIVE state 615 
can directly request SDTP communications to be renewed 
by issuing a restart signal 619 to the client device forcing a 35 
return to the LINKING state 602. After issuing a restart 
signal 619, the chent device re-enters the LINKING state 
602. 

As shown in FIG. 7, operation of a server device using the 
protocol of the present invention includes three static states 40 
(IDLE 700, READY 702 and NAHVE 711) and eight 
transitional states (TAG LINE 701, TYPE-RESPONSE 704, 
USE-RESPONSE 706, STATUS-RESPONSE 708, 
NATIVE-RESPONSE 710, DISCONNECT 713, EXIT 714 
and RESTART 715). The static slates are shown as solid 45 
circles and represent the status of the server at a given time. 
The static states are defined as follows: 

IDLE the server device is not currently in communication 

with a client device; 
READY the server device has established communication 
with the client device and is ready to receive commands 
from the client device; and 
NATIVE communication with the client device using the 
SDTP protocol has been discontinued, but the under- 
lying link is still in existence, 
'llie transitional slates are shown as diamond boxes and 
represent a particular action taken by the server. The actions 
that are included are defined as follows: 

TAG LINE the server device sends the SDTP tag line 

message to the client device; 
^TYPE-RESPONSE the server device sends the client 
device a type -response comprising a list of device and 
service identifiers; 
USE-RESPONSE the server device sends the client 65 
device a use-response explaining the operation of a 
particular service identified by the client device; 
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STATUS-RESPONSE the server device performs a 
requested service and sends a status response to the 
client device; 

NATIVE-RESPONSE the server device sends a native- 
response acknowledging that communications using 
SDTP wiU be discontinued; 

DISCONNECT the server device ends SDTP communi- 
cations with the client device and disconnects from the 
client device; 

EXIT the server device ends all communicatioas with the 
client device and disconnects from the client device; 
and 

RESTART the server device is restarted to directly reini- 
tiate further SDTP communications. 

Initially, the IDLE state 700 is active. If another device 
attempts to communicate with the server device using the 
link protocol described previously, the IDLE state 700 is 
exited and a tag line message 701 is transmitted to the client 
device. After transmitting the tag line message 701, the 
READY state 702 is entered. 

The READY state 702 is the basic operational state of the 
SDTP protocol on the server device. A transition out of the 
READY state 702 occurs in response to one of several 
events. One event is the reception of a type-command 605 
fi'om the client device. In response to a type -command event 
703, the server device sends the device id of the server 
device and its available services type-response 704 to the 
client device and returns to the READY stale 702. Another 
event that may occur is the reception of a use-command 608 
from the client device. In response to a use-command event 
705, the server device sends a use-response 706 to the client 
device and then returns to the READY state 702. Another 
event that may occur is the reception of a service-command 
611. In response to a service-command event 707, the 
identified service is performed and a service-response is sent 
708, and operation returns to the READY state 702. Another 
event that may occur is the reception of a native-command 
614 ordering SDTP protocol communications to be halted so 
that communications between the two devices may be 
carried out using a native protocol. In response to a native - 
command event 709, the server sends a native -response 710 
and then enters the NATIVE state 711. Another event that 
may occur is the reception of a quit-command 617 from the 
client device. In response to a quit-command event 712, the 
server device disconnects the client 713 and reenters the 
IDLE state 700. 

Once the NATIVE state 707 is entered, the server device 
may continue communicating with the client device using 
some other data protocol as described previously. Generally, 
when no further communication between the client device 
and the server device is desired, an exit procedure 714 is 
performed and the server returns to the IDLE state 700. 
Communications using the SDTP protocol may then be 
reinitialized as described previously. However, there are 
some cases in which a server device in the NATIVE slate 
711 can respond to a request for the renewal of SDTP 
communications directly by issuing a restart signal at 715 
and then resending the SDTP tag line message 701. 

From the foregoing description, it will be appreciated that 
the present invention provides a protocol and a method for 
facilitating communication between various electronic 
devices and enabling the devices to share features, function- 
ality and information. Although the present invention has 
been described using various examples and command 
formats, it will be appreciated that the present invention is 
not limited by these examples. 

llie present invention may be implemented and embodied 
in a variety of devices and may be implemented in software 
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or hardware. In addition, the Operation, Steps and procedures establish a communicative connection between the 

of the present invention may be implemented in a variety of device and the server device; 

programming languages. The specification and the drawings obtain service information over the communicative 

provide an ample description of the operation, steps and connection that identifies a set of services offered by 

procedures of the present invention to enable one of ordinary 5 the server device, wherein the obtaining of the ser- 

sldll in the art to implement the various aspects of the vice information by the device includes receiving a 

present invention. response to a type-command that was sent to the 

The present invention has been described in detail with server device by the device; and 

particular reference to exemplary embodiments. It is under- invoke one of the set of services offered by the server 

stood that variations and modifications can be effected device. 

within the spirit and scope of the invention, as described ^° 7. The device of claim 6, wherein the processing unit is 

herein before, and as defined in the appended clauns. The farther operative to obtain use information over the com- 

correspondmg structures, materials, acts, and equivalents of municative connection that identifies how to invoke a par- 

t'^TnZTrFtu.I^'''''^^^^^^ V f ^'^r ^^^^i^ «f the set of services offered by the particular 

are mtended to include any structure, material, or acts for , . j f 

performing the functions in combination with other claimed 15 ^^^^^^ice. „ , . ^ , . . 
elements as specifically claimed. ^ The device of claun 7 wherein the use information 
What is claimed is: identifying how to invoke a service includes identifications 
1. A method of communicating between a client device of parameters used when invoking the service and of per- 
and a server device over a communications link, the method missible values for the identified parameters, 
comprising the steps of: 9. The device of claim 6 wherein the processing unit is 
under control of a client device, initiating establishment further operative to obtain supported device information 
of a link layer connection between the client device and over the communications hnk that identifies at least one type 
a specified server device; of device that is supported by the server device, 
under control of the server device, establishing a data 10, The device of claim 9 wherein at least some of the 
connection with the cl^nt device over the link layer ^^^^ devices each support multiple types of devices by 
^ZTiX:iT^^^^^^ " -^-t " least some of those multiple device types, an^ 
with which the server device is capable of wherein the supported device m formation that is obtained by 
communicating, the established data connection based ^^"^^^^ ^^ose server devices identifies the multiple 
on the specified data protocol; and types of devices supported by those server devices, 
subsequent to the establishment of the data connection, H- A method by which a common data protocol is used 
transmitting a service -command from the client device to enable a first device of a first device type to communicate 
to the server device over the data connection, the with a second device of a second device type over a first 
service-command identifying a particular service to communications link, to enable the second device to com- 
be performed by the server device; and municate with a third device of a third device type over a 
in response to receiving the service -command at the second communications link, and to enable the third device 
server device, initiating the requested service and ^5 communicate with the first device over a third commu- 
transmitting a status-response to the client device nications link, the first device and the second device together 
over the data conriection. forming a first device pair, the second device and the third 

ro^ocd^is'sDTP ^^"^ '^'^^'^^ ^""^^^ ^ '^'^^"'^ ^'''^'^ P^^'' ^""^ ^^^^ 
^'I'^TSe method of claim 1 further comprising, prior to the 40 ^'^^^^ '"^ first device together forming a third device 

transmitting of the service-command, the steps of: P^^^' ^h^""^'" ^f the devices in each of the first, second 

transmitting a type-command from the client device to the third device pairs is a client device and the other of the 

server device over the data connection, the type- devices m each of the first, second and third device pairs is 

command requesting the server device to provide ser- ^ server device, the device pairs such that at least one of the 

vice information identifying a set of services offered by devices is a client device in one device pair and is a server 

the server device; and device in another device pair, the method comprising the 

in response to the type -command, transmitting the service steps of, for each device pair: 

information from the server device to the client device. establishing a connection between the client device of the 

4. The method of claim 3 wherein the transmitting of the device pair and the server device of the device pair 
service information further comprises transmitting a plural- using a link protocol; 

ity of device types supported by the server device. using the link protocol to establish communication 

5. The method of claim 1 further comprising, prior to the between the client device and the server device using 
transmitting of the service-command, the steps of: the common data protocol; 

transmitting a use-command from the client device to the transmitting a type-command from the client device to the 

server device over the data connection, the use- service device using the common data protocol, the 

command requesting the server device to provide use type-command requesting the service device to provide 

information describing how to invoke one of a set of service information identifying services offered by the 

services offered by the server device; and server device; and 

in response to the use -command, transmitting the use in response to the type -command, transmitting the service 

information from the server device to the client device. information from the server device to the client device, 

6. A device that is capable of communicating over a 60 12. The method of claim 11, further comprising the steps 
communications link with a plurality of server devices of a of: 

plurality of device types, the device comprising: transmitting a use-command from the client device of the 
a communications link interface; and device pair to the server device of the device pair using 
a processing unit, the processing unit being operable to the common data protocol, the use-command request- 
send and receive data over the communications link 65 ing the server device to provide use information 
and being operable to, for each of the plurahty of server describing use of one of the services offered by the 
devices: server device; and 
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in response to the use-command, transmitting the use 
informatioQ from the server device to the client device. 

13. The method of claim 11, further comprising the steps 

of: 

transmitting a service-command from the client device of 
the device pair to the server device of the device pair 
using the common data protocol, the service-command 
identifying a particular service to be performed by the 
server device; and 

in response to the service-command, initiating the 
requested service and transmitting a status-message to 
the client, 

14. A method for enabling a client device to communicate 
with a server device over a communications link, the method 
comprising the steps of: 

establishing a communicative connection with the server 
device; 

subsequent to establishing the communicative 
connection, transmitting a type-command to the server 
device, the type-command requesting the server device 
to provide service information defining a set of services 
offered by the server device; 

receiving the service information; and 

subsequent to receiving the service information, transmit- 
ting a service -command to the server device, the 
service-command identifying a particular service to be 
performed by the server device. 

15. The method of claim 14, further comprising the steps 

of: 

subsequent to establishing the communicative 
connection, transmitting a use-command to the server 
device, the use-command requesting the server device 
to provide use information defining the requirements 
for invoking one of a set of services offered by the 
server device; and 

receiving the use information. 

16. A method for enabling a server device to communicate 
with a client device over a communications link, the method 
comprising the steps of: 

establishing a communications link with the client device; 
receiving a type -command from the chent device, the 

type-command requesting the server device to provide 

service information defining a set of services offered by 

the server device; 
in response to receiving the type-command from the client 

device, transmitting the service information to the 

client device; 

receiving a service-command identifying a particular ser- 
vice to be performed by the server device; and 
initiating the requested service, 

17. The method of claim 16, further comprising the steps 

of: 

receiving a use-command from the client device, the 
use-command requesting the server device to provide 
use information defining the requirements for invoking 
one of a set of services offered by the server device; and 

in response to receiving the use-command from the client 
device, transmitting the use information to the client 
device, 

18. A device that is capable of communicating over a 
communications link with a plurality of server devices of a 
plurality of device types, the device comprising: 

a communications link interface; and 
a processing unit, the processing unit being operable to 
send and receive data over the communications link. 
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being operative to obtain supported device information 
over the communications Unk that identifies at least one 
type of device that is supported by the server device, 
and being operable to, for each of the plurality of server 
5 devices: 

establish a communicative coimection between the 

device and the server device; 
obtain service information over the communicafive 
connection that identifies a set of services offered by 
10 the server device, wherein the obtaining of the sup- 

ported device information by the device includes 
receiving a response to a type-command that was 
sent to the server device by the device; and 
invoke one of the set of services offered by the server 
device, 

19. A device that is capable of communicating over a 
communications link with a plurality of server devices of a 
plurality of device types, the device comprising: 

20 a communications link interface; and 

a processing unit, the processing unit being operable to 
send and receive data over the communications link, 
being operative to obtain use information over the 
communicative connection that identifies how to 
25 invoke a particu lar service of the set of services offered 
by the particular server device, and being operable to, 
for each of the plurality of server devices: 
establish a communicative connection between the 
device and the server device; 
30 obtain service information over the communicative 
connection that identifies a set of services offered by 
the server device, wherein the obtaining of the use 
information by the device includes receiving a 
response to a use -command that was sent to the 
server device by the device; and 
invoke one of the set of services offered by the server 
device. 

20. A method for enabling a client device to communicate 
with a server device over a communications link, the method 
comprismg the steps of: 

establishing a communicative connection with the server 
device; 

after establishing the communicative connection, trans- 
45 mitting to the server device a use-command requesting 
the server device to provide use information that 
describes how to invoke a specified one of multiple 
services offered by the server device; 
receiving the use information; and 
50 after receiving the use information, transmitting a service - 
command to the server device requesting the server 
device to invoke the specified service, the service - 
command specified in a manner based on a description 
included, in the received use information. 
55 21, 'Vhc method of claim 20 including, prior to the 
transmitting of the use-command to the server device, 
receiving service information from the server device that 
identifies the multiple services offered by the server device, 
and wherein the specified service is selected from the 
60 multiple services identified in the received service informa- 
tion. 

22. The method of claim 21 wherein the service informa- 
tion is received from the server device in response to a prior 
type-command transmitted to the server device. 

* * * «|c ♦ 
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